Flow diagrams are graphical descriptions of the flows of data and control in software systems. They are made up of nodes interconnected through arrowed lines. Nodes denote actions or components. The lines identify the data flow and the control flow between the actions or components. Several commercially available tools implement some forms of flow diagrams; WebSphere®, MQIntegrator®, Lotus® Workflow™ and more recently WebSphere Studio Application Developer Integration Edition are examples of such tools.
There are many specific kinds of technical flow diagrams, for example, Petri nets, data flow diagrams, state charts, process dependency diagrams activity diagrams, and workflows. In addition, several software developers produce middleware products that also have specific kinds of flow diagrams associated with them. In these products, the programmer, business analyst or system integrator, draws flow diagrams that are executed by associated runtime environments. The flows in these products are classified as nano-flows, micro-flows and macro-flows (also known as workflows). An example of tool and engine for micro-flow is MQIntegrator®, a program product of IBM Corporation for message routing and content reformatting, that allows the programmer to draw message-flow diagrams that describe the movement of data between information systems. The associated runtime environment executes these diagrams: i.e. combines, transforms, and delivers the messages. MQIntegrator is typically used to integrate information systems when large corporations merge with former competitors. Macro-flows use large-scale granular activities and are deployed by large-scale software components such as applications. Workflow products that model and implement business processes are examples of macro-flows. Nano-flows are flows of data and control that take place inside an object or object method. In many products, nano-flows model and implement the wiring of Java classes into programs that access legacy applications. Nano-flow, micro-flow, and macro-flow diagrams can be modelled with an extension of Meta Object Facility (MOF), called Flow Composition Model, as was previously reported by Litoiu et al. in “Flow Composition Modeling with MOF”, Proceedings of ICIES, 2001, Setubal, July 2001. Flow Composition Model is in the process of becoming an Object Management Group (OMG) standard. Meta Object Facility and Flow Composition Model are typically serialized in the XML Metadata Interchange (XMI) format based on eXtensible Markup Language (XML).
A second type of charting is frequently used for describing technical, business and other processes. This type of chart can describe parallel process steps, for example a credit granting process that includes steps of, for example, reviewing credit history, examining collateral and preparing account information, which can be carried out at the same time and which do not necessarily have dependencies each upon the other. This type of chart is typically in the form of a hierarchical tree, and includes nodes that usually contain multiple steps, each step being a child node that contains more detailed steps, and so on down to the simplest part of the process which usually contains text or code defining the process at its most detailed level. This lowest type of node is called a leaf node. A leaf node has no child nodes.
Flow diagrams are hierarchically composed. That is, a node in a flow diagram can itself be a flow diagram. There can be many levels in the hierarchy. Understanding hierarchically composed diagrams is difficult, especially with the current tools. For example, to understand what a node is really doing, the user has to open a new session or new window of the editor and then look at the flow implemented by that node. Given that there might be tens or hundreds of nodes, to see all these nodes, the user has to open as many sessions or windows. Further, the known prior art methods provide no convenient way of navigating through the large number of nodes that are present in a complex business or manufacturing process, or a complex software package.
North and Shneiderman, in “Snap-Together Visualization: A User Interface for Coordinating Visualizations via Relational Schemata”, Proceedings of the Working Conference on Advanced Visual Interfaces, ACM, 2000, pp 128-135, describe a flow visualization method with display of multiple panes of information including tree and hierarchical information. Naps and Bressler, in “A multi-windowed environment for simultaneous visualization of related algorithms on the World Wide Web”, SIGSE 1998, pp 277-281, describe a program visualization method using multiple windows. In De Pauw et al, U.S. Pat. No. 6,219,826 B1, a method is described for visualizing the execution of an object-oriented program wherein each node in a tree represents an object, and each edge between nodes represents a message between objects. Lopez, in US Patent Application Publication US2002/007483 A1, describes a flow structure markup language used for flowchart program editing and navigation for a range of programming languages. Other forms of visualization are described in U.S. Pat. Nos. 6,278,464 B1 and 5,751,288.
Despite various methods known in the art for depicting program flows, process flows and general flow illustration, there is a need for flow depiction that enables more complete understanding, particularly of complex business and industrial process flows. It would be desirable to have a viewer for manufacturing, technical and business process flows that permitted the user to view a selected portion of a flow diagram at any desired magnification, to view selected nodes in closed or in open mode, and to view a hierarchy of nodes in order to understand the depth and complexity of the process flow.